The present invention relates to the testing and debugging of integrated circuits, and more particularly, the use of on-chip-debugging circuitry in ASICs such as systems-on-a-chip.
Continuing progress in the field of semiconductor technology, and especially, semiconductor fabrication, allows more and more circuitry to be placed on a single integrated circuit. This enables an increasing number of functions to be placed on a single integrated circuit. Therefore, a set of functions which formerly would be distributed across multiple integrated circuits mounted on a printed circuit board (PCB), may now be aggregated on a single integrated circuit. Such an integrated circuit is often called a “System on a Chip” (SOC). The rapid development and commercialization of such SOCs yields new problems for the SOC programmer, system design engineer, or the system integration engineer. One such problem is the design validation and debugging of programs, either in firmware or in software, which are to run on the SOC.
Often, an SOC includes the functions of an integrated circuit called an “embedded processor.” In the past, embedded processors were more likely to be found as separate integrated circuits on PCBs. Embedded processors are microprocessors often used for controlling apparatuses and performing other tasks for which a more expensive general purpose CPU was not appropriate. Continuing progress in the field of semiconductor technology has blurred the lines between embedded processors and general purpose processors. The use of embedded processors has raised similar program testing and debugging issues as those now presented with respect to SOCs. A variety of tools have been developed to efficiently debug programs on embedded processors. One such tool is the logic analyzer, which is a general purpose tool that, when attached to an embedded processor main bus and various other pins, can provide passive data collection regarding the performance of software on an embedded processor. A pin, in this context, is a connection wire off an integrated circuit. Another tool is an in-circuit-emulator, a processor-specific tool which emulates the function of the target processor while allowing access to information about the performance of the program run on the emulated processor. Moreover, the in-circuit-emulator may change the type and kind of information to which it provides access. In addition, the in-circuit-emulator would allow the state of the embedded processor to be changed (for example, register values could be specifically and independently altered). In each case, these various tools generate data regarding the execution of a program on a processor.
Another approach to debugging embedded processors is to integrate or embed emulation circuits in the processor (called “on-chip-emulation”). This approach has become more common as embedded processors have achieved progressively higher processing speeds and register widths, thus increasing the needed output bandwidth. This type of emulation may be referred to as an On-Chip-Debug System, hereinafter “OCDS.” An OCDS consists of circuits to monitor the state of an embedded processor, to configure the state of an embedded processor, and to communicate with an external debug tool. The external debug tool is often connected to a host computer running debugging software, and acts as a translator between the OCDS and a host computer such as a PC.
It is noted that the “state” of a microprocessor is its condition given in terms of the contents of its registers, internal flags, local memory, etc. Similarly, the state of a register or other memory is its condition including the value stored within it.
A variety of protocols and standards have been established concerning embedded processors that establish parameters for OCDSs. The Joint Test Action Group standard, referred to as “JTAG”, is the IEEE standard for boundary scans (IEEE 1149.1). Among other things, it establishes the parameters for testing a series of input/output registers through a set of dedicated testing pins. JTAG is the standard interface for sending commands and performing data exchange with embedded processors. JTAG is relatively simple but comparatively slow interface, exchanging about 10 MBits/s at 10 MHz of information. It is often used even in the context of other interfaces to set up test conditions, send control commands and the like.
Another interface standard for OCDSs is the Nexus 5001 Standard for a Global Embedded Processor Debug Interface (IEEE-ISTO 5001). This interface standard is capable of a much higher bandwidth, the bandwidth necessary to deal with so-called “trace information” (see below) which can be output at a high rate, e.g. 100–200 MHz. Nexus 5001 has a number of different versions that call for different levels of control and access of the target processor. The simplest case of the Nexus 5110 standard can be implemented using a JTAG interface. The higher bandwidth of the Nexus 5001 standard is often implemented just to read out data from an embedded processor, but the bandwidth may be applied bi-directionally.
Other standards exist for implementing an OCDS in an embedded processor. Some manufactures of embedded processors create and maintain a proprietary standard for their processors. An example of a company doing so is ARM®.
Among the capabilities that an OCDS of an embedded processor should have to debug a program is the ability to collect trace information. Trace information includes program trace information such as time stamps and branch messages. The external debug tool and/or the host computer can use this program trace information to reconstruct the program flow. Another type of trace information that should be collected by the OCDS is data trace information. Data trace information is a list of reads and writes (values and locations) to memory performed by the embedded processor.
The OCDS may also have the capability of monitoring for specified events in the target processor. Such events include breakpoints and watchpoints. Break points or watchpoints are specified conditions for which the OCDS monitors the embedded processor. If a specified condition occurs (e.g., the value of specified register equals a specification) then either the operation of the embedded processor is halted (a breakpoint) or a note that the condition occurred is made (watchpoint). The OCDS should collect such event information. Preferably, the OCDS may also change the type or amount of trace information gathered as a result of a watchpoint. Further capabilities of an OCDS may include the ability to test and, potentially, alter the value in each individual register of the embedded processor, as well as other memory locations within the embedded processor.
In the past, an embedded processor may have been one of many integrated circuits on a PCB. While the debugging techniques discussed above may be applied to the embedded processor (as a separate integrated circuit), the other integrated circuits of the PCB have not heretofore had OCDS capabilities. Rather, other tests were performed on the PCB board to check the functioning of the other integrated circuits and to obtain debugging information from the other integrated circuits. These tests were necessary so the PCB as a whole could undergo testing and debugging. Note that testing usually occurs during the design phase of a project, while debugging occurs during the implementation phase. All of these tests for debugging multiple chips on a PCB face the same problem-extracting information from chips which usually have no dedicated provision for exporting or outputting state information. Often a test used for debugging a PCB connects and monitors the many lines connecting each chip of the PCB. This allows the input and output signals to the chip to be monitored. As the number of chips increases, the number of lines connecting chips to the rest of the PCB increases proportionately. Therefore, the output of information off the PCB needed to monitor and debug the PCB can also increase as needed, making such debug testing of PCBs practical.
As noted before, the variety of functions performed by multiple integrated circuits on a PCB are now being integrated onto an SOC. One of these functions is that of an embedded processor. A function on an SOC can be described as being performed by a functional unit or core of circuitry. Thus, the functions of an embedded processor may be performed by a processor core. This processor core of circuitry on an SOC will often have a fewer number of pins dedicated for its use than when the equivalent function was performed by a processor as a separate integrated circuit. Increasing the number of pins increases the manufacturing expense. Therefore, fewer pins are available for testing purposes, and on-chip debugging systems become even more important. Thus, an SOC using a processor core will dedicate valuable chip area to on-chip debugging systems. Such on-chip debugging systems, designed in accordance with standards such as NEXUS 5001 will use a set number of pins for testing. Implementation of such an on-chip debugging system for a processing core in an SOC will prevent the activity of a program within the processing core from being hidden and allow the programmer to perform design validation, testing and debugging.
However, an SOC having a processor core will include other circuit cores When the functions of such other circuit cores were performed by separate integrated circuits on a PCB, the passive data collection of the PCB tests noted above were adequate for debugging purposes. However, like the processor core, the other circuit cores will usually have proportionately less pins available than when their equivalent function was performed as a separate integrated circuit, due to the increasing expense of such pins in cost and chip area. As such, process activity in these other circuit cores will be “hidden” from (e.g. will be less accessible to) the SOC designer or programmer, as less pins, or lines or other points will be available for monitoring. Rather, information that would have passed between the integrated circuits on a PCB will now remain within the integrated circuit of an SOC and thus be unavailable for detection by a programmer by the previously described methods.
Accordingly, there is a need in the art for a new apparatus and/or method for validating and debugging an SOC efficiently.